Consistent data masking

ABSTRACT

According to one embodiment of the present invention, a system masks data objects across a plurality of different data resources. The system comprises a processor configured to include a plurality of service providers to mask the data objects, wherein each service provider corresponds to a different type of data masking for the data objects. An interface provides access to the plurality of service providers from different data-consumers to mask the data objects according to the corresponding types of data masking, wherein resulting masked data maintains relational integrity across the different data resources. Embodiments of the present invention further include a method and computer program product for masking data objects across a plurality of different data resources in substantially the same manners described above.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/058,556, entitled “CONSISTENT DATA MASKING” and filed Oct. 21, 2013,the disclosure of which is incorporated herein by reference in itsentirety.

BACKGROUND

1. Technical Field

Present invention embodiments relate to masking data, and morespecifically, to masking data objects consistently across a plurality ofdifferent data resources to protect privacy.

2. Discussion of the Related Art

Data privacy is a concern for enterprises around the world. Collection,disclosure, and protection of consumers' nonpublic personal informationor personally identifiable information (e.g., medical history, financialinformation, etc.) are governed by a range of laws and regulations(e.g., the Gramm-Leach Bliley Act; the Health Insurance Portability andAccountability Act; the European Union Data Protection Directive;privacy laws in Canada, Japan, and Australia; the Payment Card IndustryData Security Standard; the Interagency Guidelines for SafeguardingCustomer Information; Basel II operational controls and Sarbanes-Oxleyinternal controls; etc.).

To address these concerns, data masking capabilities are embedded inmost commercially available Extract, Transform, and Load (ETL) and TestData Management (TDM) products. Some database products and applicationsoftware (e.g., enterprise resource planning (ERP) applications,customer relationship management (CRM) applications, human capitalmanagement (HCM) applications, etc.) also include data maskingcapabilities. In addition, point solutions have been developed to fillparticular needs. Many companies build their own data masking solutionto fit their situation if they can find no other appropriate tool.

Many large enterprises employ dozens of mission critical softwareapplications, of which some are commercial, off the shelf applicationswhile others are customer-created. These applications may share accountinformation about the company's clients, products, and services, whichmay be subject to masking. The applications may interact with eachother. In addition, an end-user may view the data using more than one ofthe applications. When the applications are used with a varied set ofoperating systems and data sources, an enterprise may have to piecetogether a data masking strategy from various niche and/or customsolutions. These disparate solutions will use different algorithms,resulting in inconsistently masked data.

BRIEF SUMMARY

According to one embodiment of the present invention, a system masksdata objects across a plurality of different data resources. The systemcomprises a processor configured to include a plurality of serviceproviders to mask the data objects, wherein each service providercorresponds to a different type of data masking for the data objects. Aninterface provides access to the plurality of service providers fromdifferent data-consumers to mask the data objects according to thecorresponding types of data masking, wherein resulting masked datamaintains relational integrity across the different data resources.Embodiments of the present invention further include a method andcomputer program product for masking data objects across a plurality ofdifferent data resources in substantially the same manners describedabove.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Generally, like reference numerals in the various figures are utilizedto designate like components.

FIG. 1 depicts an example computing environment for an embodiment of thepresent invention.

FIG. 2 depicts a block diagram of a masking module according to anembodiment of the present invention.

FIG. 3 depicts a flow diagram illustrating an example manner of maskinginformation using a public interface according to an embodiment of thepresent invention.

FIG. 4 an example form of an input parameter string for a serviceprovider for credit card numbers according to an embodiment of thepresent invention.

DETAILED DESCRIPTION

Present invention embodiments relate to masking data objects (e.g.,replacing persons' names with fictional names, obscuring all or part ofcredit card numbers, etc.) consistently across a plurality of dataresources to protect privacy. In an example scenario, a largeorganization may support computing platforms with a variety of operatingsystems (e.g., AIX, z/OS, Linux, etc.) and data sources (e.g.,relational databases based on different relational database managementsystems (RDBMSs), flat files, spreadsheets; Extensible Markup Language(XML) files, comma separated values (CSV) files, etc.). An embodiment ofthe present invention allows the organization to mask the data in amanner that preserves relational integrity between data objects indifferent data sources. For example, persons' names may appear in both arelational database and a CSV file, and the organization may conductresearch or test new software using the data masked in such a way thateach name is always replaced with the same corresponding fictional name,whether in the database or the CSV file. Different applications, whichmay be interact with each other in an integrated manner, may use themasking services provided by a present invention embodiment and produceconsistent results.

One aspect of a present invention embodiment is to provide a common setof masking services via a flexible, common interface. A set of maskingservice providers (also referred to as providers) encapsulate datamasking algorithms for particular types of data objects (e.g., nationalidentity number (NID) (e.g., Social Security Number (SSN), CanadianSocial Insurance Number (SIN), etc.), credit card number (CCN), names,addresses, etc.) within a uniform application programming interface(API), so that different providers may be used with minimal changes tothe software calling the API. The API may be used by applicationswritten in a variety of programming languages (e.g., C, C++, Cobol,etc.). For example, masking may be incorporated via the API intoExtract, Transform, and Load (ETL) tools, Hadoop platforms, etc. Amasking grammar provides a high-level syntax that enables access to themasking service providers from high level programming and scriptinglanguages (e.g., Perl, Lua, etc.), user-defined functions within adatabase, dynamic masking clients, etc. Regardless of the manner inwhich the data masking capabilities provided by a present inventionembodiment are used, the same data may be masked identically andconsistently.

Another aspect of a present invention embodiment is to facilitate useradditions to the set of masking service providers. A service providerinterface (SPI) allows users to implement their own masking serviceproviders and plug them into the common framework so they may be used inthe same manner as other masking service providers.

A further aspect of a present invention embodiment is to perform maskingwithin a database server system. A set of user-defined functions (UDFs)and user-defined table functions (UDTFs) are installed and invokedwithin a database. These functions use the masking grammar to enable useof the masking service providers inside Structured Query Language (SQL)queries. This allows masking to be performed within the database and maybe invoked via a database stored procedure to control unit of workcommits and rollbacks. For example, a user may make a full copy of adatabase, and then execute a user defined function using a SQL statementincluding a user-defined function (UDF) to perform masking in-place onthe copy. Alternatively, a user may apply masking using the UDF whilecreating or copying a table in the database using a SQL statement.Since, the UDF is an object in the database, the masking is performedwithin the database and may consume less time than if the data wereextracted from the database, processed by a masking operation, andre-inserted into the database.

A still further aspect of a present invention embodiment is to providedynamic masking (also referred to as “on the fly” masking). For example,a query may be made against a non-masked data source using a clientapplication, and sensitive data in the result set may be maskeddynamically based on the security profile of the end-user making therequest.

Yet another aspect of a present invention embodiment is to provide amasking-on-demand application, including a command line interface, thatprovides convenient masking of common, non-relational file formats(e.g., CSV, XML, etc.) stored within various file systems (e.g., POSIX,Windows, Hadoop, etc.) and relational data sources. A wizard-drivenfront end places the power of the data masking service providers at thefingertips of the user without the complexity of implementing masking ina formal system (e.g., a test data management system, ETL system, etc.).

An example environment for present invention embodiments is illustratedin FIG. 1. Specifically, the environment includes one or more serversystems 100, one or more client or end-user systems 110, and one or moredata sources 120. Server systems 100 and client systems 110 may beremote from each other and communicate over a network 12.

Network 12 may be implemented by any number of any suitablecommunications media (e.g., wide area network (WAN), local area network(LAN), Internet, intranet, etc.). Alternatively, any number of serversystems 100, client systems 110, and data sources 120 may be local toeach other, and communicate via any appropriate local communicationmedium (e.g., local area network (LAN), hardwire, wireless link,intranet, etc.).

A server system 100 may include one or more applications 102 and maskingmodule 104. Application 102 uses masking module 104 to mask informationfrom data sources 120. Applications 102 may include user-createdapplications and/or other applications or utilities (e.g., a test datamanagement suite, masking-on-demand application, user-defined functions,etc.) that use masking module 104 via API 202 (FIG. 2) to mask data fromone or more data sources 120. The application and masking module may beimplemented across plural server systems. Alternatively, the applicationand/or masking module may reside on a client system 110 or othercomputer system in communication with the data sources.

Client systems 110 enable users to communicate with the application,masking module, and/or data sources (e.g., via network 12). The clientsystems may present any graphical user (e.g., GUI, etc.) or otherinterface (e.g., command line prompts, menu screens, etc.) to receivecommands from users and interact with the application, masking module,data sources and/or other modules or services.

Data sources 120 (e.g., include relational databases, flat files,spreadsheets, comma separated value (CSV) files, etc.) containinformation accessed by application 102 including information that maybe subject to masking.

Server systems 100 and client systems 110 may be implemented by anyconventional or other computer systems preferably equipped with adisplay or monitor, a base (e.g., including at least one processor 20,memories 30 and/or internal or external network interface orcommunications devices 10 (e.g., modem, network cards, etc.), optionalinput devices (e.g., a keyboard, mouse, or other input device), and anycommercially available and custom software (e.g., masking modulesoftware).

The masking module may include one or more modules or units to performthe various functions of present invention embodiments described below(e.g., managing resources, hashing, masking data, etc.), may beimplemented by any combination of any quantity of software and/orhardware modules or units, and may reside within memory 30 of a serversystem and/or client systems for execution by processor 20.

A block diagram of masking module 104 according to an embodiment of thepresent invention is illustrated in FIG. 2. The masking module includespublic application programming interface (API) 202, service manager 204,service provider API 206, service providers 210, utilities 212, andoperating system (OS) interface 214. The masking module may beimplemented in a module framework with layers of functionality inseparate libraries loosely coupled by the APIs.

Public API 202 is used by application 102 to communicate with themasking module (e.g., to apply masking to data from data source 120).For example, public API 202 may provide a C API comprising externalizedfunctions callable from application 102. In addition, the public API maybe used (e.g., via wrappers, mixed-language linking, etc.) byapplications built using a variety of other programming languages (e.g.,COBOL, C++, etc.). Public API 202 supports a masking provider grammarthat allows high level languages and scripting languages (e.g., Lua,Perl, etc.) to gain access to services provided by the masking module.

The public API (and the back-end, in general) is independent of the datasource. This provides the flexibility to support structured andunstructured data sources without limitation. The calling application isresponsible for extracting data from a data source and passing the datato the masking module via the public API. The input and output datastructures represent data as rows and columns/fields within the rows.Standard data types are used to represent various types of data (e.g.integer, char, null terminated strings, date, time, etc.)

Service manager 204 manages global resources for masking module 104 anddata being transported from public API 202 to individual masking serviceproviders 210. Service providers interface (SPI) 206 is a C interfacepoint to and from each masking service provider 210. Masking serviceproviders 210 may include pre-defined masking service providers (formasking, e.g., a person's ages, credit card number (CCN), e-mailaddress, national identity, city, country, etc.) and user-writtenmasking service providers. User-written service providers may be addedinto masking module 104 or may reside external to the masking module. Inaddition, masking module 104 may include utility functions 212 (e.g.,hashing functions, table lookup functions, swapping functions, etc.)that are exposed via service provider API 206 for use by pre-definedand/or user-written masking service providers. The masking serviceproviders are data source agnostic and support virtually all data typesand character sets (e.g., ASCII, Unicode, Multi-byte, etc.).

Operating system (OS) interface 214 handles operating system-specificfunctions (e.g., input/output, logging, exception handling, etc.) forthe masking module for each of the supported environments (e.g., AIX,Linux, Windows, Solaris, Hewlet-Packard UniX (HP UX), z/OS, etc.). Inaddition, OS interface 214 may handle operating system-specificfunctions for applications (e.g., in an embodiment-provided masking ondemand application).

A manner of interacting with masking module 104 from application 102according to an embodiment of the present invention is illustrated inFIG. 3. In particular, application 102 makes an initial call to themasking module via a Provider_FrmwInit function of public API 202 atstep 301.

At step 302, the masking module receives control (e.g., of programexecution on processor 20), loads other libraries (e.g., operatingsystem specific libraries), acquires resources (e.g., memory for data tobe masked, log file handles, etc.), and initializes itself to providedata masking services for any of the available masking service providers210.

At step 303, the application prepares a data structure for communicatinginformation to the masking module. This structure identifies thespecific masking service provider needed by the application and controlparameters to drive execution of the masking service provider. Theapplication then calls the masking module via a Provider_Init functionof public API 202 to initialize (e.g., load dictionaries, set processingoptions, etc.) the specified masking service provider.

At step 304, the masking module receives control, interprets the inputstructure, acquires resources, loads a library containing the specifiedmasking service provider, and initializes the service provider for datamasking. The masking module returns a token identifier to theapplication. This token identifier is passed by the application to themasking module in subsequent service calls to identify the specified andinitialized masking service provider or masking service providerinstance from any other masking service providers that may be operatingin the same process.

At step 305, the application prepares the input structure with one ormore input buffers for the data to be masked and with the tokenidentifier returned from the Provider_Init function call. The maskingmodule may process masking tasks as single entities or in user-definedbatch sizes. The application then calls a Provider Service function ofpublic API 202 to mask the data identified in the one or more inputbuffers.

At step 306, the masking module receives control, interprets the tokenidentifier, interprets the input buffer(s), masks the data, and returnsthe masked data to the application. The masked data is returned eitherin the input buffer(s), or optionally, in corresponding outputbuffer(s).

At step 307, the application determines whether more data remains to bemasked. If so, processing returns to step 305. Otherwise, at step 308,the application calls a Provider_Term function of the public API(passing the token identifier in the call) to terminate use of thespecified masking service provider by that application.

At step 309, the masking module receives control, interprets the tokenidentifier, releases resources, and terminates the masking serviceprovider specified by the token identifier for the application.

At step 310, the application calls the masking module via aProvider_Frmw/Term function of the public API to allow the maskingmodule framework to be terminated.

At step 311, the masking module receives control, releases resources,and terminates the masking module framework environment.

An example using the masking service provider for credit card numbers(CCNs) illustrates the masking grammar. Example keywords and parameters(some common to all masking service providers, some specific to the CCNprovider) are described, followed by examples of the use of the CCNprovider in a UDF and within a Lua script. An input parameter stringcontains control information using the masking grammar. An example formof the input parameter string for a CCN service provider according to anembodiment of the present invention is illustrated in FIG. 4. A requiredparameter named PRO (or PROVIDER) specifies the masking serviceprovider. For example, the term PRO=CCN specifies that the provider forcredit card numbers is requested.

A required parameter FLDDEFn describes the attributes of a field. The nsuffix correlates to the index of the field, argument or field-namespecified in the query or expression. For example, FLDDEF1 describes theattributes of the first field. FLDDEF2 describes the attributes of thesecond field, etc. The FLDDEF parameter includes sub-parameters enclosedwithin parenthesis to separate them from other parameters.

In particular, a required FLDDEF sub-parameter NAME specifies the fieldname. For example: FLDDEF1=(NAME=FIELD1) indicates that field number 1is named “FIELD1.”

A required FLDDEF sub-parameter named DT (or DATATYPE) specifies thedata type of the field. Example values, and their characteristics, thatmay be assigned to the DT sub-parameter include the following:

i) CHAR

Fixed size character data which is left justified and space padded.

ii) DATE

The date is contained within three consecutive shorts integers. Thefirst is a signed short that contains the year, the second is anunsigned short that contains the month and the third is an unsignedshort that contains the day. In a C-type structure format the dateappears as:

typedef struct s_odbc_date { signed short  Year; unsigned short  Month;unsigned short  Day; } ODPP_ODBC_DATE;

iii) DATETIME_CHAR

This a fixed size character data containing a date-time value that isleft justified and space padded.

iv) DATETIME_SZ

This is a character data string containing a date-time value that isleft justified, space padded and terminated by a NULL character.

v) DATETIME_VARCHAR

This is a variable size character data starting with a short integervalue which indicates the length, in bytes, of the character date-timevalue that follows.

vi) DATETIME_WCHAR

This is a fixed size wide-character data containing a date-time valuethat is left justified and space padded.

vii) DATETIME_WSZ

This is a wide character data string containing a date-time value thatis left justified, space padded and terminated by a NULL character.

viii) DATETIME_WVARCHAR

This is a variable size wide character data starting with a shortinteger value which indicates the length, in bytes, of the widecharacter date-time value that follows.

ix) DECIMAL_(—)370

This is an IBM mainframe 370/MVS/ESA/zOS packed decimal encoded buffer.A packed decimal field has two decimal numbers expressed in a singlebyte of storage in all but the rightmost/last portion of a packeddecimal field. The last rightmost/last byte has the sign indicator inthe rightmost/last part of the byte. The standard signs used a 0xF forpositive numbers and 0xD for negative numbers.

x) DOUBLE

This is a double precision floating point number. Range of values:1.7E+/−308 (15 digits).

xi) FLOAT

This is a floating point number. Range of values: 3.4E+/−38 (7 digits).

xii) INTEGER

This is a 4-byte signed integer. Range of values: −2,147,483,648 to2,147,483,647.

xiii) LONG_LONG

This is an 8-byte signed numeric value. Range of values:−9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.

xiv) ORA_VARNUM

This is an Oracle VARNUM-type. It is similar to the Oracle externaldatatype NUMBER except that the first byte contains the length of thenumber representation. The length value does not include the length byteitself. The user must reserve 22-bytes to use the longest possibleVARNUM where the 1st byte is the length and bytes 2-through 22 containthe 21-binary format of the Oracle NUMBER-type.

) xv) SMALLINT

This is a 2 byte signed integer value. Range of values: −32,768 to32,767

xvi) TIME

) The time is contained in three consecutive unsigned shorts. The firstcontains the hour, the second contains the minute and the third containsthe second. In a C-type structure format the time appears as:

typedef struct s_odbc_time { unsigned short  Hour; unsigned short Minute; unsigned short  Second; } ODPP_ODBC_TIME;

xvii) TIMESTAMP

The timestamp is contained in a consecutive arrangement of six shortsfollowed by an unsigned integer. The first is a signed short thatcontains the year, the second is an unsigned short that contains themonth, the third is an unsigned short that contains the day, the fourthis an unsigned short that contains the hour, the fifth is an unsignedshort that contains the minute the sixth is an unsigned short thatcontains the second and at the end of this consecutive arrangement is anunsigned integer that contains the fractional second. In a C-typestructure format the timestamp appears as:

typedef struct s_odbc_timestamp { signed short  Year; unsigned short Month; unsigned short  Day; unsigned short  Hour; unsigned short Minute; unsigned short  Second; unsigned int  Fraction; }ODPP_ODBC_TIMESTAMP;

) xviii) U_INTEGER

This is a 4 byte unsigned integer value. Range of values: 0 to4,294,967,295.

xix) U_LONG_LONG

This is an 8-byte unsigned numeric value. Range of values: 0 to18,446,744,073,709,551,615,

xx) U_SMALLINT

This is a 2-byte unsigned integer value. Range of values: 0 to 65,535

xxi) U_TINYINT

This is a single byte unsigned integer value. Range of values: 0 to 255

xxii) VARCHAR

This indicates character data starting with a short integer value whichindicates the length, in bytes, of the character data to follow.

xxiii) VARCHAR_SZ

This indicates character data string which is terminated by a NULLcharacter.

xxiv) WCHAR

This is a fixed size wide character data which is left justified andspace padded.

xxv) WVARCHAR

This is wide character data starting with a short integer value whichindicates the length, in bytes, of the wide character data to follow.

xxvi) WVARCHAR_SZ

This is wide character data string which is terminated by a NULLcharacter.

For example, the expression FLDDEF1=(NAME=FIELD1, DT=WCHAR) specifiesthat field number 1 is named “FIELD1” and has a data type of WCHAR.

In some cases, e.g., for some UDFs, some information is not neededbecause it can be determined within the UDF.

An optional FLDDEF sub-parameter named LEN (or LENGTH) specifies thelength of a character field as an integer value. This parameter isrequired only when this information is not available within theenvironment in which the masking module is executing, and is used onlywith character data types (e.g., CHAR, VARCHAR, VARCHAR_SZ, WCHAR,WVARCHAR, WVARCHAR_SZ, DATETIME_CHAR, DATETIME_SZ, DATETIME_VARCHAR,DATETIME_WCHAR, DATETIME_WSZ, DATETIME_WVARCHAR). For example, theexpression FLDDEF1=(LEN=10, NAME=FIELD1, DT=WVARCHAR) specifies thatfield number 1 has data type WVARCHAR and is ten characters long.

An optional FLDDEF sub-parameter named PRE (or PRECISION) specifies theprecision of a numeric field. This parameter is required only when thisinformation is not available within the masking module executingenvironment. The value of this field is an integer that specifies theprecision of field. For example, the expression FLDDEF1=(PRE=5,NAME=FIELD2, DT=DOUBLE) indicates that field number 2 has a precision offive digits.

An optional FLDDEF sub-parameter named SCA (or SCALE) specifies thescale of a numeric field. This parameter is required only when thisinformation is not available within the masking module executingenvironment. Its value is a short integer that specifies the scale ofthe field. For example, the expression FLDDEF1=(PRE=5, SCA=2,NAME=FIELD2, DT=DOUBLE) indicates that field number 2 has a precision offive and a scale of two.

An optional FLDDEF sub-parameter named CP (or CODEPAGE) specifies thecode page of the data. This parameter is required only when: the type ofdata is CHAR, VARCHAR, VARCHAR_SZ, DATETIME_CHAR, DATETIME_SZ, orDATETIME_VARCHAR; and this information is not available within themasking module executing environment, the CP/CODEPAGE parameter was notspecified outside of the FLDDEF, or the code page of the data for thesubject FLDDEF is different than the CP/CODEPAGE specified outside ofthe FLDDEF. This parameter takes an integer value that specifies thecodepage or character-set identifier. For example, FLDDEF1=(CP=1252,NAME=FIELD3, DT=CHAR) specifies code page 1252.

An optional FLDDEF sub-parameter named CPT or CPTYPE specifies the codepage type. This parameter is required only when: the type of data isCHAR, VARCHAR, VARCHAR_SZ, DATETIMEI_CHAR, DATETIME_SZ, orDATETIME_VARCHAR; the CP/CODEPAGE sub-parameter is specified; and thisinformation is not available within the ODPP executing environment, theCPT/CPTYPE parameter was not specified outside of the FLDDEF, or thesource of the data for the subject FLDDEF is different than theCPT/CPTYPE specified outside of the FLDDEF.

The following Table 1 identifies the code page type abbreviations basedupon the data source:

TABLE 1 Code page type abbreviations Type Values Data Source DBZ orDB2zOS DB2 z/OS DB2 or DB2LUW DB2-LUW ORA or ORACLE Oracle SYB or SYBASESybase ODBC ODBC IFX or INFORMIX Informix MSS or SQLSERVER MS SQL ServerTD or TERADATA Teradata NZ or NETEZZA Netezza ANY any DBMS NONE no DBMS

In many cases, the source of the input data is a DBMS in which case aDBMS-type code page type value is required. This ensures that themasking module handles the data using DBMS-specific code pages. When theorigin of the data is DBMS specific but not tied to any one DBMS, thenthe value should be specified as ANY. When the origin of the data isfrom a non-DBMS source, then the value should be specified as NONE.

An example expression using CP and CPT is the following:FLDDEF1=(CP=943, CPT=DB2, NAME=FIELD=4, DT=VARCHAR). This expressionspecifies that the code page for the field is DB2.

Parameters that are specified within the input parameter string and thatare used for more than one of the masking service provider specificgrammar include CP (or CODEPAGE), CPT (or CPTYPE), and DLIM (orDISCARDLIMIT).

CP specifies the code page of the data for all data-related input. Thisparameter may be optionally overridden within a FLDDEFn-type parameterwhen there is a difference in the code pages between fields within thesame syntax expression. This allows the masking module to handle dataexpressed in different code pages between different fields. The defaultis UTF-8 (Unicode). The parameter takes an integer value that specifiesthe codepage or character-set identifier.

CPT is an optional parameter that specifies the code page value. Thiscode page type applies to all data-related input. This parameter may beoptionally overridden within a FLDDEFn-type parameter when there is adifference in the code page types between fields within the same syntaxexpression. This allows the masking module to handle data expressed indifferent DBMS-specific code pages.

The DLIM parameter specifies the number of failed rows that should bediscarded or ignored before a process takes an action. The particularaction depends on the specific implementation (e.g. Lua, UDF, etc.). Forexample, the expression DLIM=10 specifies that ten rows are to bediscarded.

The input to an masking module-based UDF is specified with the followingformat:

OptimMask<ret-type> ( argument-1 , ... argument-n , ‘ODPP-provider-input-syntax ’).

The term OptimMask<ret-type> is the name of the ODPP-type UDFs.<ret-type> is the return data type from the UDF which is based upon thecategorization of data types that are supported within each DBMS. Theterms argument-1, . . . argument-n are the input arguments to the UDF.At least one argument is required as the object of the UDF. Thisargument may be any type of SQL expression supported by the hostingDBMS. In many cases, this will simply be the name of the source column.The string ‘ODPP-provider-input-syntax’ is the syntax expression that isinput to the ODPP-specific service provider, for example:

SELECTCCNCol, OptimMaskStr800Latin (CCNCol,  ‘pro=ccn,mtd=repeatable,flddef1 = (name=CCNvc, dt=char) ’) MaskedCCN from TestTable.

In the above example, OptimMaskStr800Latin is the name of the maskingmodule-based UDF, which can return VARCHAR string of max. 800characters; CCNCol is the table column-name to be masked; ‘pro=ccn,mtd=repeatable, flddef1=(name=CCNvc, dt=char)’ is the ODPP syntax thatis requesting the masking module CCN service provider. The method ofmasking is repeatable.

Scripts (e.g., Lua scripts) may be used for customized column processingwith a database. These scripts may invoke masking module 104 to maskdata values. A call to a masking service provider from a Lua script usesthe same masking grammar as described above in the context of a UDF. Forexample, the following Lua code may be used to generate a masked valuevia the masking service provider for credit card numbers (CCN).

VALUE = source.field.getvalue(“CreditCardNum”)     -- get CreditCardNumfield value MASK_VALUE = OptimMaskStr800Latin(VALUE,    ‘pro=ccn,mtd=repeatable,    flddef1=(name=CCNvc,dt=char)’)target.field.setvalue(MASK_VALUE)

It will be appreciated that the embodiments described above andillustrated in the drawings represent only a few of the many ways ofimplementing embodiments for masking data objects consistently across aplurality of different data resources to protect privacy.

The environment of the present invention embodiments may include anynumber of computer or other processing systems (e.g., client or end-usersystems, server systems, etc.) and storage systems (e.g., file systems,databases, or other repositories), arranged in any desired fashion,where the present invention embodiments may be applied to any desiredtype of computing environment (e.g., cloud computing, client-server,network computing, mainframe, stand-alone systems, etc.). The computeror other processing systems employed by the present inventionembodiments may be implemented by any number of any personal or othertype of computer or processing system (e.g., desktop, laptop, PDA,mobile devices, etc.), and may include any commercially availableoperating system and any combination of commercially available andcustom software (e.g., database software, communications software,etc.). These systems may include any types of monitors and input devices(e.g., keyboard, mouse, voice recognition, touch screen, etc.) to enterand/or view information.

The various functions of the computer or other processing systems may bedistributed in any manner among any number of software and/or hardwaremodules or units, processing or computer systems and/or circuitry, wherethe computer or processing systems may be disposed locally or remotelyof each other and communicate via any suitable communications medium(e.g., LAN, WAN, intranet, Internet, hardwire, modem connection,wireless, etc.). For example, the functions of the present inventionembodiments may be distributed in any manner among various serversystems, end-user/client and/or any other intermediary processingdevices including third party client/server processing devices. Thesoftware and/or algorithms described above and illustrated in the flowcharts may be modified in any manner that accomplishes the functionsdescribed herein. In addition, the functions in the flow charts ordescription may be performed in any order that accomplishes a desiredoperation. Application 102, masking module 104, and some or allcomponents thereof may be coupled in any manner (e.g., staticallylinked, dynamically linked, inline, within the same process or separateprocesses, within the same or separate processors, etc.).

The communication network may be implemented by any number of any typesof communications network (e.g., LAN, WAN, Internet, Intranet, VPN,etc.). The computer or other processing systems of the present inventionembodiments may include any conventional or other communications devicesto communicate over the network via any conventional or other protocols.The computer or other processing systems may utilize any type ofconnection (e.g., wired, wireless, etc.) for access to the network.Local communication media may be implemented by any suitablecommunication media (e.g., local area network (LAN), hardwire, wirelesslink, Intranet, etc.).

The system may employ any number of data storage systems and structuresto store information. The data storage systems may be implemented by anynumber of any conventional or other databases, file systems, caches,repositories, warehouses, etc.

The present invention embodiments may employ any number of any type ofuser interface (e.g., Graphical User Interface (GUI), command-line,prompt, etc.) for obtaining or providing information, where theinterface may include any information arranged in any fashion. Theinterface may include any number of any types of input or actuationmechanisms (e.g., buttons, icons, fields, boxes, links, etc.) disposedat any locations to enter/display information and initiate desiredactions via any suitable input devices (e.g., mouse, keyboard, touchscreen, pen, etc.).

It is to be understood that the software of the present inventionembodiments could be developed by one of ordinary skill in the computerarts based on the functional descriptions contained in the specificationand flow charts illustrated in the drawings. Further, any referencesherein of software performing various functions generally refer tocomputer systems or processors performing those functions under softwarecontrol. The computer systems of the present invention embodiments mayalternatively be implemented by any type of hardware and/or otherprocessing circuitry.

The present invention embodiments are not limited to the specific tasks,algorithms, parameters, data, or network/environment described above,but may be utilized for any type of data object masking.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, “including”, “has”, “have”, “having”, “with”and the like, when used in this specification, specify the presence ofstated features, integers, steps, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operations, elements, components,and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

What is claimed is:
 1. A computer implemented method of masking dataobjects across a plurality of different data resources comprising:accessing a plurality of service providers to mask the data objects,wherein each service provider corresponds to a different type of datamasking for the data objects, via an interface that provides access tothe plurality of service providers from different data-consumers to maskthe data objects according to the corresponding types of data masking,wherein resulting masked data maintains relational integrity across thedifferent data resources.
 2. The computer implemented method of claim14, wherein the data-consumers include at least one of user generatedapplications and user defined functions.
 3. The computer implementedmethod of claim 14, wherein the interface includes a grammar to enabledata-consumers implemented by at least one of computing and scriptinglanguages to access the plurality of service providers to mask the dataobjects.
 4. The computer implemented method of claim 14, wherein atleast one service provider includes a user generated service providerperforming a corresponding type of data masking, and the interfaceincludes: a provider interface to enable the data-consumers to access atleast one user generated service provider.
 5. The computer implementedmethod of claim 14, wherein the interface includes an ApplicationProgramming Interface (API).
 6. The computer implemented method of claim14, wherein each data resource includes one of a data source, a dataapplication, and an operating platform.
 7. The computer implementedmethod of claim 14, wherein the data-consumers are associated withdifferent contexts of data and applications and the data masking of theservice providers is applied to the different contexts.